DNS Management for Servers Lab

1. Configure unbound as a Caching Nameserver

In this lab, you configure unbound as a caching nameserver and administer its cache data.

You were asked to improve name resolution performance and enhance DNS security in your company’s datacenter. You decided to deploy a caching nameserver using an unbound DNS server. You want to configure unbound to respond only to queries on the datacenter subnet, 192.168.0.0/24. You also want to forward recursive queries to the company’s main internal DNS server at 192.168.0.254. This main internal DNS server hosts an internal, split DNS copy of the company’s example.com zone. This example.com zone is not DNSSEC-signed, so it must be exempt from DNSSEC validation on your caching nameserver. After configuring the caching nameserver on server1.example.com, you test it by querying for the host names desktop1.example.com and server1.example.com from desktop1.example.com. Verify that the queries are populated into the nameserver’s cache. Lastly, you purge server1.example.com from the cache.

  1. Reset the server1.example.com system.

  2. Log in to the server1.example.com switch to root using sudo -i.

  3. Install the unbound package on server1.example.com.

    [root@server1 ~]# yum install -y unbound

  4. Enable and start the unbound service.

    [root@server1 ~]# systemctl enable unbound.service
ln -s '/usr/lib/systemd/system/unbound.service' '/etc/systemd/system/multi-user.target.wants/unbound.service'
[root@server1 ~]# systemctl start unbound.service

  5. Configure unbound to allow queries from the 192.168.0.0/24 subnet, exempt the example.com zone from DNSSEC validation, and forward all queries to 192.168.0.254.

    1. By default, unbound listens on the loopback interface. Configure unbound to listen on the 192.168.0.101 interface on server1.example.com by adding the following option in the server clause of /etc/unbound/unbound.conf.

      interface: 192.168.0.101

    2. Allow queries from the 192.168.0.0/24 subnet by adding the following option in the server clause of /etc/unbound/unbound.conf.

      access-control: 192.168.0.0/24 allow

    3. Exempt the example.com zone from DNSSEC validation by adding the following option in the server clause of /etc/unbound/unbound.conf.

      domain-insecure: "example.com"

    4. Forward all queries to 192.168.0.254 by adding a forward-zone clause to the end of the /etc/unbound/unbound.conf file.

      forward-zone:
            name: .
            forward-addr: 192.168.0.254

  6. Check /etc/unbound/unbound.conf for syntax errors.

    [root@server1 ~]# unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf

  7. Restart the unbound service.

    [root@server1 ~]# systemctl restart unbound.service

  8. Configure the firewall to allow DNS traffic.

    [root@server1 ~]# firewall-cmd --permanent --add-service=dns
success
[root@server1 ~]# firewall-cmd --reload
success

  9. Verify the caching name service by performing queries and examining the contents of the cache.

    1. Dump the cache to see its contents.

      [root@server1 ~]# unbound-control dump_cache
    START_RRSET_CACHE
    END_RRSET_CACHE
    START_MSG_CACHE
    END_MSG_CACHE
    EOF

    2. From desktop1.example.com, query server1.example.com for the A record of host name desktop1.example.com.

      [student@desktop1 ~]$ dig @server1.example.com A desktop1.example.com
...
desktop1.example.com.   86349   IN  A   192.168.0.1
...

    3. From desktop1.example.com, query server1.example.com for the A record of host name server1.example.com.

      [student@desktop1 ~]$ dig @server1.example.com A server1.example.com
...
server1.example.com.    86364   IN  A   192.168.0.101
...

  10. On server1.example.com, dump out the cache again. You should see the queried records in the cache.

    [root@server1 ~]# unbound-control dump_cache
START_RRSET_CACHE
;rrset 85886 1 0 8 3
server1.example.com.  85886   IN  A   192.168.0.101
;rrset 85878 1 0 8 X
desktop1.example.com.  85878   IN  A   192.168.0.1
;rrset 85878 1 0 7 3
example.com.    85878   IN  NS  instructor.example.com.
;rrset 85878 1 0 3 3
instructor.example.com. 85878   IN  A   192.168.0.254
END_RRSET_CACHE
START_MSG_CACHE
msg desktop1.example.com. IN A 33152 1 85878 3 1 1 1
desktop1.example.com. IN A 0
example.com. IN NS 0
instructor.example.com. IN A 0
msg server1.example.com. IN A 33152 1 85886 3 1 1 1
server1.example.com. IN A 0
example.com. IN NS 0
instructor.example.com. IN A 0
END_MSG_CACHE
EOF

  11. Purge the server1.example.com record from the cache.

    [root@server1 ~]# unbound-control flush server1.example.com
ok

  12. On server1.example.com, dump out the cache again. You should no longer see the A record for server1.example.com in the cache.

    [root@server1 ~]# unbound-control dump_cache
START_RRSET_CACHE
;rrset 85878 1 0 8 X
desktop1.example.com.  85878   IN  A   192.168.0.1
;rrset 85878 1 0 7 3
example.com.    85878   IN  NS  instructor.example.com.
;rrset 85878 1 0 3 3
instructor.example.com. 85878   IN  A   192.168.0.254
END_RRSET_CACHE
START_MSG_CACHE
msg desktop1.example.com. IN A 33152 1 85878 3 1 1 1
desktop1.example.com. IN A 0
example.com. IN NS 0
instructor.example.com. IN A 0
msg server1.example.com. IN A 33152 1 85886 3 1 1 1
server1.example.com. IN A 0
example.com. IN NS 0
instructor.example.com. IN A 0
END_MSG_CACHE
EOF

2. Troubleshoot DNS

In this lab, you troubleshoot and resolve a name resolution issue by systematically verifying name service configurations to pinpoint the cause.

A user reports that there is an issue occurring when an SSH session is initiated to example.com from server1.example.com and a "Could not resolve hostname example.com: Name or service not known" error is being generated. Therefore, the user complains that there is a problem with DNS name resolution of example.com. Like all other hosts on the network, server1.example.com should be using 192.168.0.254 for DNS resolution.

You need to troubleshoot the issue, identify the root cause, apply a fix, and then verify that the problem is resolved.

You cannot actually log in to example.com using SSH. Seeing a login prompt is all that is required, and you can cancel the login prompt by pressing Ctrl+C.

  1. Reset the server1.example.com system.

  2. Log in to and set up the server1.example.com system.

    [student@server1 ~]$ wget -O - http://instructor.example.com/pub/server1-dns.sh | bash

  3. Replicate the reported issue by attempting an SSH session to example.com from server1.example.com.

    [student@server1 ~]$ ssh example.com
ssh: Could not resolve hostname example.com: Name or service not known

  4. Verify the result of name resolution for example.com.

    [student@server1 ~]$ getent hosts example.com
[student@server1 ~]$

    1. Verify the order that name services are used.

      [student@server1 ~]$ grep ^hosts: /etc/nsswitch.conf
hosts:      files dns

    2. Since files are used first, verify the contents of /etc/hosts.

      [student@server1 ~]$ grep [[:space:]]example.com /etc/hosts
[student@server1 ~]$

    3. Since no hosts file entry exist for example.com, verify the contents of /etc/resolv.conf; you should see that an incorrect nameserver IP is the cause of the name resolution failure.

      [student@server1 ~]$ grep ^nameserver /etc/resolv.conf
nameserver 192.168.0.255
      [student@server1 ~]$ dig @192.168.0.255 A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @192.168.0.255 A example.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

  5. As root, fix the error in /etc/resolv.conf and verify that this resolves the name resolution issue.

    1. Because the nameserver entry populated by DHCP was manually modified, as root, force a refresh of the data from DHCP and validate that the entry is fixed.

      [student@server1 ~]$ sudo systemctl restart NetworkManager
      [student@server1 ~]$ grep ^nameserver /etc/resolv.conf
nameserver 192.168.0.254

    2. Verify the results of name resolution for example.com.

      [student@server1 ~]$ getent hosts example.com
192.168.0.254  example.com
      [student@server1 ~]$ dig A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> example.com
;; global options: +cmd
;; Got answer:
;; -->>HEADER<<-- opcode: QUERY, status: NOERROR, id: 36048
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        86400   IN  A   192.168.0.254

;; AUTHORITY SECTION:
example.com.        86400   IN  NS  classroom.example.com.

;; ADDITIONAL SECTION:
classroom.example.com.  86400   IN  A   192.168.0.254

;; Query time: 1 msec
;; SERVER: 192.168.0.254#53(192.168.0.254)
;; WHEN: Thu May 15 07:28:35 EDT 2014
;; MSG SIZE  rcvd: 96

    3. Verify that SSH connection to example.com from server1.example.com now succeeds.

      [student@server1 ~]$ ssh example.com
The authenticity of host 'example.com (192.168.0.254)' can't be established.
ECDSA key fingerprint is 12:b3:c8:3e:6b:d2:9f:43:67:a5:f2:2a:f0:7c:2f:b6.
Are you sure you want to continue connecting (yes/no)?

3. Manage DNS for Servers

In this lab, you use DNS troubleshooting techniques and knowledge of unbound configuration to resolve DNS issues with a misconfigured unbound caching nameserver.

To improve DNS performance and security, a fellow system administrator has recently configured a secure caching nameserver running the unbound DNS server on server1.example.com to serve your local subnet, 192.168.0.0/24.

The caching nameserver uses DNS server 192.168.0.254 for name resolution. The administrator released the caching nameserver for use just prior to leaving for a week-long vacation.

Soon after your colleague leaves, you receive reports of DNS issues from users trying to use the newly configured caching nameserver for the first time. One user provides a specific example and reports that name resolution for example.com fails.

You need to troubleshoot and correct the unbound misconfiguration that is causing this issue.

  1. Reset your server1.example.com system.

  2. Log in to and set up your server1.example.com system.

    [student@server1 -]$ wget -O - http://instructor.example.com/pub/server1-unbound.sh | bash

  3. On desktop1.example.com, replicate the reported issue to determine the nature and scope of the problem.

    1. From desktop1.example.com, issue a query for the address of example.com to the caching nameserver on server1.example.com.

      [student@desktop1 -]$ dig @server1.example.com A example.com
  ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @server1.example.com example.com
  ; (1 server found)
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  4. Verify the operation of the caching nameserver on server1.example.com by issuing queries to it locally from server1.example.com.

    1. Issue the query to the localhost interface. The query succeeds with no errors.

      [student@server1 -]$ dig @localhost A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @localhost A example.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64095
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        84526   IN  A   192.168.0.254

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed May 21 05:12:00 EDT 2014
;; MSG SIZE  rcvd: 56

    2. Issue the query to the 192.168.0.101 interface. No response is received and the query times out.

      [student@server1 -]$ dig @192.168.0.101 A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @192.168.0.101 A example.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

    3. Determine which interfaces unbound is listening on. You should discover that it’s only listening on the localhost interface.

      [student@server1 -]$ sudo ss -tulpn | grep -w 53
tcp    UNCONN     0      0              127.0.0.1:53                    *:*      users:"unbound",2192,5
tcp    UNCONN     0      0                    ::1:53                   :::*      users:"unbound",2192,3
tcp    LISTEN     0      5              127.0.0.1:53                    *:*      users:"unbound",2192,6
tcp    LISTEN     0      5                    ::1:53                   :::*      users:"unbound",2192,4

  5. Fix the issue discovered and verify that it resolved the name resolution issue.

    1. Configure unbound to listen on all interfaces by adding the following entry in /etc/unbound/unbound.conf.

      interface: 0.0.0.0

    2. Check the configuration for syntax errors.

      [student@server1 -]$ sudo unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf

    3. Restart the service for the changes to take place.

      [student@server1 -]$ sudo systemctl restart unbound

    4. On server1.example.com, rerun the query to the 192.168.0.101 interface. You should now receive a response, but with a status of REFUSED.

      [student@server1 -]$ dig @192.168.0.101 A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @192.168.0.101 A example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 50719
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; Query time: 0 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed May 21 05:36:43 EDT 2014
;; MSG SIZE  rcvd: 12

  6. While the DNS communication now works, the return code in the DNS response indicates that there may be another misconfiguration issue present. Verify the unbound configuration on server1.example.com.

    1. Since REFUSED status indicates a policy restriction, verify that the proper access policy is in place in /etc/unbound/unbound.conf. You should see that no access control has been granted for the subnet.

      [student@server1 -]$ sudo grep ^[[:space:]]*access-control /etc/unbound/unbound.conf

  7. Fix the issue discovered and verify that it resolved the name resolution issue.

    1. Grant the 192.168.0.0/24 subnet access to the caching nameserver in /etc/unbound/unbound.conf.

      [student@server1 -]$ sudo grep ^[[:space:]]*access-control /etc/unbound/unbound.conf
    access-control: 192.168.0.0/24 allow

    2. Check the configuration for syntax errors.

      [student@server1 -]$  sudo unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf

    3. Restart the service for the changes to take place.

      [student@server1 -]$ sudo systemctl restart unbound

    4. On server1.example.com, rerun the previously failed query. It should now succeed.

      [student@server1 -]$ dig @192.168.0.101 A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @192.168.0.101 A example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25229
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        86339   IN  A   192.168.0.254

;; Query time: 0 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed May 21 05:56:16 EDT 2014
;; MSG SIZE  rcvd: 56

    5. On desktop1.exampl.com, rerun the query to server1.example.com. It should now succeed.

      [student@desktop1 -]$ dig @server1.example.com A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @server1.example.com A example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25229
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        86339   IN  A   192.168.0.254

;; Query time: 0 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed May 21 05:56:16 EDT 2014
;; MSG SIZE  rcvd: 56